[SYCL] Differentiate install targets for `clang*` binaries by dm-vodopyanov · Pull Request #21598 · intel/llvm

dm-vodopyanov · 2026-03-23T17:09:11Z

This PR adds the following:

The following symlinks in CMAKE_INSTALL_PREFIX/bin folder: dpclang, dpclang++, dpclang-cl, dpclang-cpp, dpsycl-ls, dpsycl-prof, etc. They WON'T point to real clang, clang++, etc binaries. They point to the tool below.
Adds a tool similar to AMD's amdllvm tool: https://github.com/ROCm/llvm-project/tree/amd-staging/clang/tools/amdllvm. It is called dpllvm. What it does - when we run dpclang++ symlink, it runs dpllvm tool. dpllvm gets "clang++" from "dpclang++" and executes clang++. The same will be with every other symlinks which start wqith dp. clang can run itself inside itself, so we need to keep the name of the binary - clang++. BTW, the same on Windows - but we will have tiny binaries dpclang, dpclang++, etc - as Windows does not support symlinks. So we will avoid renaming clang++ to dpclang++ on Windows and the size of binary distribution on Windows won't be bigger - there won't be copies of clang, clang-cl, etc binaries.
Adds dpllvm and dpclang, dpclang++, dpclang-cl, dpclang-cpp, dpsycl-ls, dpsycl-prof, etc. not only to CMAKE_INSTALL_PREFIX/bin but also to build/bin - and use these binaries everywhere in LIT tests (like it is already done in this PR)

This patch renames `clang`, `clang++`, `clang-c++`, `clang-cc`, `clang-cpp`, `clang-g++`, `clang-gcc`, `clang-cl` to the same names with a prefix `dp` to make sure the SYCL compiler package can be co-existed with the official clang package for various Linux distributions.

sarnex · 2026-03-23T17:16:55Z


      SmallString<128> ClangPath(C.getDriver().Dir);
-      llvm::sys::path::append(ClangPath, "clang");
+      llvm::sys::path::append(ClangPath, "dpclang");


We probably need to change sycl/doc as well

tahonermann · 2026-03-23T17:37:23Z

Thanks, @dm-vodopyanov. This is more change than I was expecting. How did you identify all the places to change? Trial and error by running the testsuite? Or a more systematic approach?

dvrogozh

That's just a partial solution as it takes care to rename only clang* kind of things and leaves behind a bunch of lvm-* binaries, include/clang/, libLLVM*, etc. I would like to propose alternative solution which I hope will be easier:

Change the install prefix for all the stuff borrowed from LLVM. Let default be $libdir/dpclang-MAJOR/ as that's prescribed default by File System Hierarchy Standard. This will immediately resolve all the potential conflicts with already installed LLVM.
Install additional targets, symlinks with the original names likes dpclang-MAJOR

Above will create the following installation target (assuming the default for LLVM installation):

$bindir/dpclang ->$prefix/bin/dpclang-MAJOR
$bindir/dpclang-MAJOR 
....
$libdir/libsycl.so.VERSION
$libdir/dpcpp-MAJOR/bin/clang
$libdir/dpcpp-MAJOR/bin/clang++
$libdir/dpcpp-MAJOR/bin/llvm-ar
...

sarnex · 2026-03-24T22:05:05Z

I don't think this PR intended to solve the complete problem, I think it's just one piece of a larger set of changes.

If we try to implement all of those in one PR it will become huge, impossible to review, and more likely to have bugs.

tahonermann · 2026-03-25T14:26:52Z

I would like to propose alternative solution which I hope will be easier

I tend to agree with @dvrogozh's alternate suggestion. What he proposes is similar to what is done for the oneAPI icx compiler distribution (that distribution puts the LLVM utilities in a compiler directory under $bindir).

@dvrogozh, could you please quote the section of the File System Hierarchy Standard that you feel justifies placing the LLVM assets under $libdir?

dvrogozh · 2026-03-25T15:29:09Z

@dvrogozh, could you please quote the section of the File System Hierarchy Standard that you feel justifies placing the LLVM assets under $libdir?

It's section 4.6.1, https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html:

"/usr/lib includes object files and libraries. On some systems, it may also include internal binaries that are not intended to be executed directly by users or shell scripts.

Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory."

Note that Debian's and Ubuntu's /usr/lib/x86_64-linux-gnu/ location is their own extension of the FHS /usr/lib defined in FHS, see https://wiki.ubuntu.com/MultiarchSpec.

Also, to place internal stuff to $libdir/<component>/ folder was the direction we've got from Debian/Fedora maintainers once we were packaging other projects (drivers) in these distributions.

This reverts commit e6cb663.

tahonermann · 2026-05-29T21:40:31Z

@dm-vodopyanov, I see the changes are currently marked Linux only. Can you confirm that is just temporary? My expectation is that the new targets will be provided on Windows as well.

sarnex · 2026-07-07T14:32:01Z

@sarnex @bader @intel/dpcpp-clang-driver-reviewers @wenju-he @Maetveis @intel/llvm-reviewers-cuda @pbalcer - this is ready for the final review.

The structure on build/install folder now looks like this:

Linux: install-linux.txt Windows: install-windows.txt

@dm-vodopyanov Can you please update these files with your latest commit (reverting the devicelib change)? Seeing the install dirs will greatly help my ability to review, thanks

dm-vodopyanov · 2026-07-07T14:34:34Z

@sarnex @bader @intel/dpcpp-clang-driver-reviewers @wenju-he @Maetveis @intel/llvm-reviewers-cuda @pbalcer - this is ready for the final review.
The structure on build/install folder now looks like this:
Linux: install-linux.txt Windows: install-windows.txt

@dm-vodopyanov Can you please update these files with your latest commit (reverting the devicelib change)? Seeing the install dirs will greatly help my ability to review, thanks

Yes, I'm actually working on this, building LLVM locally

Upd.: updated the files

sarnex

i am not an expert in this code either but overall lgtm, just some relatively minor comments

sarnex · 2026-07-07T15:12:33Z

 /// Check "-fsycl-is-device" is passed when compiling for device:
 // RUN:   %clang -### -fsycl-device-only --no-offload-new-driver %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-SYCL-DEV %s
-// CHECK-SYCL-DEV: "-fsycl-is-device"{{.*}} "-internal-isystem" "{{.*}}bin{{[/\\]+}}..{{[/\\]+}}include{{[/\\]+}}sycl{{[/\\]+}}stl_wrappers" "-internal-isystem" "{{[^"]*}}bin{{[/\\]+}}..{{[/\\]+}}include"


can you explain what the actual change in cc1 command is?

The driver now derives the root via findSYCLInstallRoot(D), which normalizes the path (walks up and resolves), so bin/.. is collapsed out

got it, thx

sarnex · 2026-07-07T15:13:42Z

+  # actually exists rather than hardcoding a path that only works for one build
+  # layout.
+  foreach(path ${CMAKE_MODULE_PATH})
+    if(EXISTS ${path}/LLVMInstallSymlink.cmake)


sorry i dont think my previous comment is resolved, do we really need to check the entire cmake_module_path, can we just use find_file?

Should be resolved now, thanks

sarnex · 2026-07-07T15:18:10Z

+# ld.lld/ld64.lld/lld-link/wasm-ld symlinks); redirect it too so the linkers
+# don't collide with a system LLVM. The real lld binary destination is patched
+# separately in lld/cmake/modules/AddLLD.cmake, mirroring add_clang_tool.
+set(LLD_TOOLS_INSTALL_DIR "${DPCPP_INSTALL_INTERNAL_BINDIR}" CACHE PATH "" FORCE)


Just wondering, I'm surprised we starting seeing a collision with system lld with this PR and need a workaround, any idea why?

These binaries were in the main bin/ folder, so I moved them to lib/dpcpp-7/bin/ folder. Saw that only on Windows.

Looking at the install-linux.txt and install-windows.txt files, it looks like lld is only built for Windows. Is that intentional?

Looks like yes:
https://github.com/intel/llvm/blob/sycl/buildbot/configure.py#L160

# lld is needed on Windows or when building AMDGPU

Why this is true, I have no idea.

bader · 2026-07-07T16:32:17Z


    if (LLD_BUILD_TOOLS)
+      # Install the real lld binary into the versioned DPC++ tools dir (e.g.
+      # lib/dpcpp-N/bin) so it doesn't conflict with a system LLVM, matching


Installing lld binary to lib sub-directory doesn't make sense to me. Please, fix the comment (and implementation if needed).

The request was to keep only DPC++-related binaries in bin/ folder.

Please, put binaries to bin sub-directory (e.g. bin/llvm-bin/).

There may be concerns from Canonical - "llvm-bin" is too basic name, for our compiler we need customizations. Also I don't know the whole story but looks like we can't use bin/ folder for that. So @dvrogozh suggested to use lib/dpcpp-N/bin.

+ @tahonermann for opinions

lib is for libraries. bin is for binaries.
Putting binaries to lib sub-directory if we can put them into bin sub-directory doesn't make sense.
Intel oneAPI puts llvm binaries to bin/compiler directory to address the conflict with LLVM package.

Do we really need to have dp* links for sycl-* tools? I don't think LLVM packages include sycl-* tools.

IMO it's useful for user experience to teach users stuff starting with dp is from intel's sycl compiler

Future LLVM packages will include a sycl-ls utility. The DPC++ package that Canonical will be distributing includes the SYCL utilities with a dp prefix, so this is consistent.

Future LLVM packages will include a sycl-ls utility.

I'm not sure if distributing sycl-* tools as LLVM package is a good idea. I would prefer to have a separate package for them.

I think the sycl-* utilities should be part of the LLVM project. How Linux distributors package them is up to them of course, but we can encourage them to place them in a separate package. They may opt to do so anyway. The Canonical package includes dpsycl-ls with dpclang and the other dp prefixed utilities in the dpclang package.

wenju-he

libclc change LGTM

bratpiorka

CUDA LGTM

sarnex

lgtm, just one comment, nice!

dm-vodopyanov · 2026-07-10T16:38:45Z

Failure in SYCL Benchmarks is unrelated: #22599

No more changes in upstream files -> I'm happy.

dm-vodopyanov · 2026-07-10T18:36:15Z

All failures are unrelated to this patch:

SYCL :: KernelAndProgram/level-zero-static-link-flow.cpp - #22192
Hang tests - #22601

…22603) This PR adds the following: * The following symlinks in `CMAKE_INSTALL_PREFIX/bin` folder: `dpclang`, `dpclang++`, `dpclang-cl`, `dpclang-cpp`, `dpsycl-ls`, `dpsycl-prof`, etc. They WON'T point to real `clang`, `clang++`, etc binaries. They point to the tool below. * Adds a tool similar to AMD's `amdllvm` tool: https://github.com/ROCm/llvm-project/tree/amd-staging/clang/tools/amdllvm. It is called `dpllvm`. What it does - when we run `dpclang++` symlink, it runs `dpllvm` tool. `dpllvm` gets "clang++" from "dpclang++" and executes `clang++`. The same will be with every other symlinks which start wqith `dp`. `clang` can run itself inside itself, so we need to keep the name of the binary - `clang++`. BTW, the same on Windows - but we will have tiny binaries `dpclang`, `dpclang++`, etc - as Windows does not support symlinks. So we will avoid renaming `clang++` to `dpclang++` on Windows and the size of binary distribution on Windows won't be bigger - there won't be copies of `clang`, `clang-cl`, etc binaries. * Adds `dpllvm` and `dpclang`, `dpclang++`, `dpclang-cl`, `dpclang-cpp`, `dpsycl-ls`, `dpsycl-prof`, etc. not only to `CMAKE_INSTALL_PREFIX/bin` but also to `build/bin` - and use these binaries everywhere in LIT tests (like it is already done in this PR) Fixes #21511 --------- --------- Co-authored-by: dmitry.vodopyanov <dvodopya@smtp.igk.intel.com>

dm-vodopyanov requested review from a team as code owners March 23, 2026 17:09

dm-vodopyanov requested a review from cperkinsintel March 23, 2026 17:09

sarnex reviewed Mar 23, 2026

View reviewed changes

dvrogozh reviewed Mar 24, 2026

View reviewed changes

dm-vodopyanov added 3 commits May 29, 2026 21:22

Revert "[SYCL] Rename clang binaries to dpclang"

d8939da

This reverts commit e6cb663.

Merge remote-tracking branch 'origin/sycl' into rename_clang_to_dpclang

0e2ecdb

Apply CR comments

6b896ba

dm-vodopyanov requested a review from bader as a code owner May 29, 2026 19:26

Move sycl-ls back to install/bin folder

a678dba

dm-vodopyanov changed the title ~~[SYCL] Rename clang binaries to dpclang~~ [SYCL] Differentiate install targets for clang* binaries May 29, 2026

Make it only for Linux`

814058d

dm-vodopyanov marked this pull request as draft May 29, 2026 19:47

dm-vodopyanov added 2 commits May 29, 2026 22:55

Fix regressions + add a test

e0be600

Small fix

4d91d11

dm-vodopyanov changed the title ~~[SYCL] Differentiate install targets for clang* binaries~~ [SYCL] Differentiate install targets for clang* binaries May 29, 2026

dm-vodopyanov added 2 commits May 29, 2026 23:06

Fix formatting

56207c8

Fix formatting

8110571

dm-vodopyanov added 4 commits June 3, 2026 20:10

Update CI

1b19d13

Try to fix CI for Linux

1139beb

Fix CI on Linux

fc08eb4

Fix CI

417df3d

sarnex reviewed Jul 7, 2026

View reviewed changes

Apply CR comments

b7171a2

dm-vodopyanov requested a review from sarnex July 7, 2026 16:12

bader reviewed Jul 7, 2026

View reviewed changes

mdtoguchi reviewed Jul 7, 2026

View reviewed changes

Comment thread clang/lib/Driver/ToolChains/CommonArgs.cpp Outdated

Apply CR comments

05e80f6

dm-vodopyanov requested a review from mdtoguchi July 7, 2026 16:59

mdtoguchi reviewed Jul 7, 2026

View reviewed changes

Comment thread clang/lib/Driver/ToolChains/SYCL.cpp Outdated

mdtoguchi reviewed Jul 7, 2026

View reviewed changes

Comment thread clang/lib/Driver/ToolChains/SYCL.cpp Outdated

wenju-he approved these changes Jul 8, 2026

View reviewed changes

bratpiorka approved these changes Jul 8, 2026

View reviewed changes

Apply CR comments

7f5938b

dm-vodopyanov requested a review from a team as a code owner July 10, 2026 15:34

dm-vodopyanov requested review from bader and mdtoguchi July 10, 2026 15:38

Fix clang-format

26b9b59

sarnex approved these changes Jul 10, 2026

View reviewed changes

Comment thread clang/tools/dpllvm/dpllvm.cpp Outdated

Fix for Windows

d0d0167

sarnex approved these changes Jul 10, 2026

View reviewed changes

dm-vodopyanov added 2 commits July 10, 2026 18:49

Fix for Windows in-tree tests

8da7edf

Fix clang-format

45c68d1

mdtoguchi approved these changes Jul 10, 2026

View reviewed changes

lslusarczyk approved these changes Jul 10, 2026

View reviewed changes

dm-vodopyanov merged commit 328217f into intel:sycl Jul 10, 2026
48 of 53 checks passed

Uh oh!

Conversation

dm-vodopyanov commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tahonermann commented Mar 23, 2026

Uh oh!

dvrogozh left a comment

Choose a reason for hiding this comment

Uh oh!

sarnex commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tahonermann commented Mar 25, 2026

Uh oh!

dvrogozh commented Mar 25, 2026

Uh oh!

tahonermann commented May 29, 2026

Uh oh!

sarnex commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dm-vodopyanov commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sarnex left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dm-vodopyanov Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wenju-he left a comment

Choose a reason for hiding this comment

Uh oh!

bratpiorka left a comment

dm-vodopyanov commented Mar 23, 2026 •

edited

Loading

sarnex commented Mar 24, 2026 •

edited

Loading

sarnex commented Jul 7, 2026 •

edited

Loading

dm-vodopyanov commented Jul 7, 2026 •

edited

Loading

dm-vodopyanov Jul 7, 2026 •

edited

Loading